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(57) ABSTRACT 

A system and method are provided for a scalable and 
efficient multipoint-to-multipoint multicast in packet and 
sub-packet based communications networks. The method- 
ology of the invention incorporates an additional switching 
feature called cut-through forwarding, which enables the 
mapping of several incoming virtual channels into one or 
several outgoing virtual channels. The inventive methodol- 
ogy further provides a shared tree spanning all senders and 
receivers of the multicast group. Centrally initiated group 
setup as well as dynamic group membership changes are 
incorporated into the invention. An additional feature of the 
invention, designated "short-cutting", allows for the trans- 
mission of a packet to follow the shortest path along the 
shared tree. A methodology is also provided for achieving 
interoperability among switching nodes in a network which 
are capable of fully implementing the multipoint-to- 
multipoint multicast method of the invention and other 
switching nodes which lack that capability. 

41 Claims, 4 Drawing Sheets 
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SYSTEM AND METHOD FOR MULTIPOINT- 
TO-MULTIPOINT MULTICASTING 

FIELD OF THE INVENTION 

This application is related to multicasting in communica- 
tions networks and more particularly to an improved method 
for providing multipoint-to-multipoint multicasting in sub- 
packet switched communications networks. 

BACKGROUND OF THE INVENTION 

Point-to-point communication across a communications 
network among a single sender and a single receiver is well 
known and networking protocols for point-to-point commu- 
nications services are well established. Increasingly, 
however, a communications arrangement needs to be estab- 
lished among multiple senders and/or multiple receivers 
constituting a group having some community of interest. 
Accordingly, the concept of a group multicast service has 
evolved for enabling multiple senders to communicate to 
multiple receivers. It is known in the art to provide a point 
to multipoint connection. However, there is no present 
methodology for efficiently providing a multicast service 
between multiple senders and multiple receivers. 

Networking applications can benefit in terms of 
scalability, performance and design simplicity from a group 
multicast service, i.e., a service enabling multiple senders to 
communicate to multiple receivers. Examples of multicast- 
ing on a broad scale include human collaboration such as 
video-conferencing and shared workspaces. Additionally, 
many applications in Local Area Networks (LANs) have 
often taken multicasting for granted (e.g., for address 
resolution, resource discovery, etc.). Moreover, it is believed 
that the need for multicasting will become even more 
pressing with the wide-scale deployment of distributed 
systems (e.g., maintaining replicated databases). 

A number of approaches have been suggested for imple- 
mentation of a multipointto-multipoint multicasting service 
in a communications network- In the Internet Protocol (IP) 
environment, two noteworthy approaches are the Core 
Based Tree ("CBT") approach and the Protocol Independent 
Multicast ("PIM") approach. The basic idea of CBT [see, T. 
Ballardie, P. Francis, and J. Crowcroft, "Core Based Trees 
(CBT)" in Proc, ACM SIGCOMM 93, (San Francisco, 
Calif.), September 1993] is to have a single tree per group, 
rooted at a core router. This tree is shared between all the 
senders to the group. A multicast group is set up by first 
choosing one (or several) core routers, and making them 
known to potential receivers. Receivers can then join the 
multicast group by sending join messages towards the core. 
As soon as the join message either reaches the core or a 
router that is part of the requested group's tree, the new 
receiver is attached to the tree. Senders simply unicast 
packets to the core. The core then forwards packets to the 
receivers in the group by "multicasting** the packet on the 
tree. 

Two problems are associated with CBT. First, the reli- 
ability of the entire group is tied to the reliability of the core. 
If the core fails, the entire group fails. Second, the price paid 
by having a single tree shared by all senders sending to this 
group are traffic concentration and possibly increased delays 
as compared to having multiple sender-based shortest path 
trees. Moreover, the core may be a bottleneck, which con- 
tributes to the delays as a result of queuing. 

PIM [see, S. Deering, et al, "An Architecture for Wide- 
Area Multicast Routing", in Proc. ACM SIGCOMM '94, 
(London), August 1994] attempts to combine the advantages 
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of CBT with those of sender-based shortest path trees. By 
default, a multicast group gets set up as a core-based tree. 
However, a receiver has the option to request getting packets 
from a given sender on the shortest path, rather than through 
5 the core-based tree. The receiver chooses the option so as to 
minimize the delay, which may be useful in real-time 
communication. Both CBT and PIM exploit point-to- 
multipoint capability already present in IP-based packet 
networks. 

10 As sender-based trees require per-sender state both in the 
sender-based tree itself and the shared tree (negative-cache 
entries saying "do not forward packets from sender S out this 
interface"), a large number of senders can only be supported 
on the shared tree. Furthermore, the soft-state approach in 

1S PIM requires refreshing this state on a regular basis. This 
traffic also grows with the number of senders that are 
supported by sender-based trees. The operation of switching 
a sender from a shared to a sender-based tree is relatively 
costly and results in a transition period where loss can occur. 

20 Finally, joins of new receivers get more costly as the number 
of senders supported by sender-based trees increases (in the 
straightforward one-tree-per-sender case, a receiver has to 
join all of the trees of all of the interesting senders) because 
the new receiver has to learn of the existence of these 

25 senders, which happens by temporarily grafting them back 
onto the shared tree. 

For networks based on the Asynchronous Transfer Mode 
(ATM) networking protocol, other multicasting approaches 
have been considered. At a base level, ATM multicasting 

30 may be implemented as a mesh of point-to-point virtual 
circuits — i.e., by establishing individual point-to-point com- 
munications paths among all combinations of senders and 
receivers in such a multicast group. It will be apparent that 
such an embodiment would be highly resource intensive 

35 because each sender/receiver communications path would 
have to be configured using a separate virtual circuit, likely 
resulting in performance degradation (including duplicate 
transmission over the network links) as well as cost penal- 
ties. Moreover, it is often the case that virtual circuits are a 
scarce commodity. 

It is also known in the art to implement an ATM point- 
to- multipoint service, wherein a "tree" is established repre- 
senting a communications path from a single sender to 
multiple receivers. In such a tree, the sender can be seen as 

45 the root of the tree and each receiver as a branch of the tree. 
In such a point-to-multipoint service, common communica- 
tions packets intended for multiple receivers are replicated at 
the branching point(s), rather than at the root, thus avoiding 
the need for redundant transmissions to those branching 

50 points. However, in order for multiple senders to multicast 
to a set of receivers, the use of such a point-to-multipoint 
approach results in multiple trees, all trying to talk to the 
same set of receivers. 
The above limitation on multiple senders multicasting to 

55 multiple receivers has been addressed by the use of multicast 
servers — i.e., the establishment of an infrastructure of point- 
to-multipoint connections along with a server to achieve 
muttipoint-to-multipoint communication. Specifically a 
multicast server is established to which all the senders send 

60 on distinct point-to-point circuits. The server sequences the 
information and sends it out on a point-to-multipoint con- 
nection to the ultimate receivers. The members of the 
multicast group form a multicast "cluster** and establish a 
connection to the multicast server, which itself establishes a 

65 point-to-multipoint connection to the receivers. 

This approach suffers from the parallel deficiencies of 
requiring the dedication of a server to each multipoint-to- 
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multipoint connection, and, where sub-packet communica- FIG. 3 depicts the operation of the "Receivers Down- 

tions networks are involved, as with ATM, also requiring stream** element of the invention. 

reassembly of incoming sub-packets at the multicast server, FIG. 4 provides an illustration of the operation of the 

before queuing them to be forwarded on the single point- short-cutting function of the invention. 

to-multipoint connection to the receivers. Such a dedicated 5 pjQ 5 illustrates an interoperability between network 

server represents not only a critical failure pomt that can take sw i t ches in which the methodology of the invention is 

down the entire multicast arrangement, but also introduces 1^^^ othe r switches which are unable to carry 

significant latency as each arriving packet must be reas- QUt that mcmo dology. 

sembled before being forwarded to the receivers. Moreover, 

where one or more receivers are located at a branching point 10 DETAILED DESCRIPTION OF THE 

between a sender and the server, it is necessary for packets INVENTION 
to be forwarded from that sender all the way to the server 

and then back to the receiver, thus introducing both latency For clarity of explanation, the illustrative embodiment of 

and the overhead of multiple traversal of the same path for the present invention is presented as comprising individual 

such packets. is functional blocks (including functional blocks labeled as 

"processors'*). The functions these blocks represent may be 

SUMMARY OF THE INVENTION provided through the use of either shared or dedicated 

A system and method for implementation of multipoint- hardware, including, but not limited to, hardware capable of 

to-multipoint multicasting service in packet-based commu- executing software. For example the functions of processors 

nications networks, such networks being comprised of inter- 20 presented in FIG. 1 may be provided by a single shared 

connected switching nodes and transmission links defining processor. (Use of the term "processor** should not be 

transmission paths therein, such system and method being construed to refer exclusively to hardware capable of 

provided by carrying out the following steps: executing software.) 

specifying a unique identifier for association with each of Environment For Practice Of Invention 

a set of senders and receivers comprising a given z:> 

multicast group; As is well known, networks are a principal means of 

selecting at least one switching node in such a network to exchanging or transferring information (e.g., data, voice, 

act as an anchor for signalling messages sent toward text, video, etc.) among communications devices (i.e., 

that anchor from senders/receivers comprising the devices for inputting and or outputting information such as 

given multicast group; 30 computer terminals, multimedia workstations, fax machines, 

defining a distribution tree for the given multicast group, printers, servers, telephones, videophones, etc.) connected to 

such distribution tree including the anchor and a set of the network(s). A network typically comprises switching 

signalling paths connecting that anchor with all nodes connected to each other, and to communication 

senders/receivers identified by that unique identifier; devices, by links. Each link is characterized by a link 

causing communications paths to be established among capacity which will generally be specified as a bandwidth or, 

switching nodes and transmission links included in the equivalently, a transmission rate. When information is to be 

distribution tree, for transmission of information exchanged between two communications nodes/devices a 

between senders and receivers in the given multicast P ath is csUb^hed withm the network connecting the nodes 

erouo* and (hereafter called the origination and destination nodes) with 

, ... , . 1 . A • 1 j 40 which those devices are associated. Such a communications 

where a switching node in the dilution tree includes Qf cfa a ^ ^ destination 

parallel input paths, from multiple senders m the given * of a «, 0 f physical paths (i.e., serially 

multicast group, causmg each such switchmg node to ^ Md meir nodes ^ ^ the 

completely process an information segment of pre- ^ destination nodes) ^ netW0lk 

defined size received from a first such input path prior 45 ^ 7 

to processing any portion of another information seg- FIG- 1 shows an exemplary wide area network illustrative 

ment received from another such input path. of the configuration and operation of a contemporary com- 

In a further embodiment of the invention, the system and munications network. Network 110 comprises a plurality of 

method for implementation of multipoint-to-multipoint mul- switchmg nodes 120 1 and finks 130*. Each of the nodes 

ticasting service carries out the further step of: 50 1304 may dso have associated therewith a buffer of prede- 

. . . j . 4 . ... termined size and each of the links 130- A: will have associ- 

causing each switching node in a communications path in , . . . u , t . , , «- , , r 

. f . . . . . £ _ ated therewith a predetermined traffic handling capacity, 

the tree to operate on an information packet from a ^ T r _ 1 • • f * 

a * a ♦ 1 t t u r . , ^ A Note that the depiction of a network comprising only five 

sender transmitted toward the anchor, so as to cause a , . _ r . j f , 

c r *• *j a a- A *i nodes is tor convenience 01 illustration, and that an operat- 

copy of such information packet to be provided directly . t t « , ' . - . r , 

to a receiver in the given multicast group served by a 55 m * Qetwork ma > have a ™<J lar & cr Dumbcr of nodcs and 

communications path connected in the tree hierarchy at me associated connecting hnks. 

or below the location of that switching node, whereby Various nodes are shown illustratively connected to Corn- 
only information packets destined to receivers served munications Devices 105./. It should be understood that the 
by communications paths connected in the tree hierar- single communications devices shown connected to the 
chy at or beyond the anchor need be transmitted to and 60 nodes in the figure are used for simplicity of illustration, and 
processed by the anchor. mal m actual implementation of such a network would 

ordinarily have a number of communications devices con- 

BRIEF DESCRIPTION OF THE DRAWINGS nected at such nodes. Note, as well, that the illustrated 

FIG. 1 depicts an exemplary network configuration for communications devices may also represent another 

implementing the system of the invention. 65 network, such as a LAN, which is connected to network 110. 

FIG. 2 provides a schematic depiction of the cut-through Each communications device 105-;' generates information 

function for the methodology of the invention. for use by, or receives information from, other communica- 
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tions devices in the network. The term "information" as used users are not the immediate senders/sinks of the data being 

herein is intended to include data, text, voice, video, etc. transmitted. Examples include name services, replicated 

Information from communications device 105-/ is charac- databases, resource discovery, distribution services (such as 

terized by a set of transmission and/or rate parameters financial data), and collection services (collect data from 

related to network link and buffer requirements needed to 5 field sensors). Another example would be the emulation of 

accommodate transmission of such information. LANs, where it is assumed that multipoint-to-multipoint 

In the design and operation of an information network, communication is available. While this group of applica- 

such as network 110, a concept that is frequendy applied is tions is still relatively immature, it is believed to represent 

that of a logical or virtual circuit or virtual connection a bigger challenge for a multicast service design. Overall, it 

between a sending and receiving communications device in 1Q can be expected that both the total network size and the size 

the network. The basic idea of a virtual connection is that of of potential multicast groups will grow substantially in the 

a logical partitioning of a physical network into a number of relatively near future, and that the variety of applications 

virtual circuits generally serving different users and/or ser- relying on multicast will become more diverse, 

vices. Such a virtual connection generally follows a single As noted in the Background section, a multicast service 

physical path (comprising a series of interconnected links offers significant advantages over using a collection of 

between a sending and a receiving communications device) 15 point-to-point (unicast) links. The most obvious advantage 

at any given time. It should be understood, however, that & &om ^ perspective of bandwidth usage: a packet 

multiple virtual circuits may share capacity in a single s* ni to a number of receivers will traverse each link only 

physical path through a network oa f e * mu l^ast is used, because the packet is replicated 

„ . t . *_ i • only when the paths to the receivers diverge. However, to 

Communications networks will often use a networking „„ J , n- i • • tU * i*j i _ - 

. 11JA . „ _ w , / 4q n A B 20 reach multiple receivers in the umcast case, multiple copies 

protocol called Asynchronous Transfer Mode (ATM) oftbe ^ ' ket ^ ^ ^ ^ mult £ le ^ 

Indeed, it is generally believed that, within the next 5-10 Another advantage of mu iti C ast is the group abstraction that 

years, most of the voice and data traffic generated through- such a can provide. Senders and receivers need not 

out the world will be transmitted by ATM technology. be aware of the identity or address of other members of the 

Broadband packet networks based on Asynchronous Trans- 2$ group. For them, the group exists as a single object that can 

fer Mode are enabling the integration of traffic with a wide be addressed as a single entity. The availability of such a 

range of characteristics within a single communication net- service often simplifies the design and implementation of 

work. In these networks, all communication at the ATM distributed systems, as membership information is 

layer is in terms of fixed-size packets, called "cells'* in ATM decoupled from the application. For example, the applica- 

terminology. An ATM cell consists of 48 bytes of payload 3Q tion does not need to be informed about dynamic member- 

and 5 bytes for the ATM-layer header. Routing of cells is ship changes. A multicast service thus provides an essential 

accomplished through packet switches over Virtual Connec- glue to assemble distributed systems, 

tions (hereafter "VCs") sctu P Dctweencn dpoints. Packets of It is suggested that a multicast service addressed to the 

information may be broken up (or segmented) into multiple applications described above should encompass the follow- 

cells, each cell carrying the 48 bytes of information sequen- 35 ing set of objectives: 

tially. The destination reassembles the cells received into the Group management symmetry for senders and receivers; 

original packet. The assumption, at least for cells using the Scalability as a function of the total network size, the 

AAL5 adaptation layer protocol, is that all of the cells of a sizCj md me frequency of membership changes; 

packet are delivered in order for a given VC, and hence can Distributed management, for example joins and leaves 

be assembled as they arrive in order. ^ initiated by members (senders or receivers or both) that 

II. Methodology Of Invention are invisible to other members — or, at least, which do 

A. Introduction not introduce an overhead on other members; and 

There are several applications that gain from an efficient smooth migration from current point-to-multipoint capa- 

multicasting infrastructure. This efficiency generally trans- bilities. 

lates to allowing large scale group communication, where 45 The methodology of the invention described hereafter 

the complexity and overhead for communication does not provides a realization of such objectives, 

grow unreasonably with the number of participants in the B. Overview of Methodology 

group. The invention disclosed herein is described in the context 
Multicast "users" can be broadly divided into two general of a preferred embodiment represented by an implementa- 
types: humans and machines. The human group has received 50 tion of the inventive methodology in an ATM network. It 
more attention in the past, probably because the need for should be recognized, however, that concepts taught by the 
multicast is more obvious. Candidate applications for a disclosure herein will be applicable to the provision of 
multicast service include anything involving shared com- multicasting service in other communications networks, 
munication among more than two users, such as conference particularly other packet and sub-packet networks, 
phone calls, videoconferencing, television (unidirectional or 55 The development of ATM networks is fueled by the need 
interactive), whiteboard, etc. This group of applications is for efficient utilization of wide -are a network resources, 
rather well understood today, at least insofar as human users scalable bandwidth and support for quality of service. The 
are known to have difficulty in focusing on multiple simul- underlying mechanism is the use of Virtual Connections 
taneous input streams. Thus it appears unlikely mat multi- (VCs), where state for conversations in progress is main- 
cast groups involving human collaboration will arise with 60 tained in the network's switches. The natural way VCs are 
large numbers of simultaneous senders. However, for set up is to associate state for a sender-receiver pair. While 
machine-oriented multicast applications, there is much rea- this is suitable for unicast (i.e., point-to-point) 
son to expect a large number of simultaneous senders, and communication, it becomes state-intensive to use the same 
the need for scalability in such multicast applications, as to method for multicast service. Accordingly, a methodology is 
both senders and receivers is substantial. 65 disclosed herein for providing a scalable and efficient 
Machine-oriented multicast applications can usefully be multipoint-to-multipoint multicast service in sub-packet net- 
characterized as comprising all applications where human works. 
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A defining property of the novel multipoint-to-multipoint tion. Additionally, through the application of a unique addi- 

multicast methodology disclosed herein is a shared tree tional switching feature (called "cut-through" and described 

between all senders and receivers of a group. The concept of more fully hereafter), a single VC can be used for the entire 

a "core", as suggested by Ballardie, et al. [T. Ballardie, P. tree, thus conserving this potentially scarce resource. In a 

Francis, and J. Crowcroft, "Core Based Trees (CBT)" in 5 further embodiment of the invention, a novel signalling 

Proc. ACM SIGCOMM 93, (San Francisco, Calif.), Septem- mechanism (termed "short-cutting" and more fully 

ber 1993], is used as the root of the tree to be set up. Unlike described hereafter), permits a beneficial modification to the 

the CBT core, however, which is a server through which all way cells are forwarded in the switches: to wit, instead of 

messages are funneled, the core for the invention acts packets first being sent to the core and then multicast back 

primarily as an anchor for forwarding signalling messages, 10 to the receivers, as in the MARS methodology described by 

as explained more fully below. Thus with the methodology Armitage [G. J. Armitage, "Multicast and Multiprotocol 

of the invention, every router/switch in the tree participates Support for ATM Based Internets," A CM Sigcomm Com- 

in the forwarding of traffic, including the router/switch puter Communications Review, vol 25, April 1995], short - 

which was chosen to be the core for signaling purposes. cuts can be taken at each switch on the tree. In other words, 

Having a single shared tree per group has a number of 15 each packet spans the shared tree from its sender to all the 

important advantages. First, a group will allocate only one receivers, keeping delays low. 

VC per link — i.e., a common VC serves all senders and Signalling for the multipoint-to-multipoint multicast 

receivers in the group. Relatedly, no per-sender state has to methodology of the invention is based on a group handle. A 

be maintained in switches. Intra-group consistency will also handle is a unique conversation identifier for the inventive 

be more easily achieved: if all senders send on a common 20 methodology. That handle is used in signalling messages to 

tree, then a receiver joining this tree is sure to receive from facilitate the association of appropriate input and output 

all the senders. Alternatively, if the group exists as a col- ports/VCs for the multicast group in the core and each of the 

lection of sender-based trees, then it is not easy for the switches/routers in the tree — i.e., the handle for a particular 

receiver to ensure that it has joined all of these trees. multicast group enables the mapping of input VCs for that 

Additionally, a single tree multicasting methodology per- 25 group at a particular switch to the corresponding output 

mits several group members to be added in one step, VC(s) at that switch (in accordance with a routing table set 

initiated by the core. In a methodology involving per-sender up in each such switch). The handle consists of the core 

trees, this is not so readily achieved: either each sender has address plus an identifier. The core address is necessary 

to set up a tree to all the receivers, which means that the set because it allows members and intermediate switches to 

of receivers has to be communicated to the senders, or the 30 know the core through the group handle. Note that to make 

receivers join the sender tree for all the senders, which the handle globally unique, it is sufficient to make the 

means that, in turn, the receivers need to know the set of additional identifier locally (at the core) unique, 

senders. This can be an important performance consider- C. Detailed Description of Methodology 

ation for applications that depend on rapid setup of centrally For convenience of reference in the discussion following 

controlled groups. 35 of the methodology of the invention, that inventive meth- 

It is known that a disadvantage of shared trees is the odology will be designated by the acronym SEAM [Scalable 

possibility of transmission delays that are higher than in the Efficient ATM Multicasting]. It is also to be noted that 

case of shortest-path sender-based trees [See, L. Wei and D. additional background for the SEAM methodology is pro- 

Estrin, "The Trade-OAs of Multicast Trees and Algorithms", vided in an article prepared by the inventors entitled: 

in Proc. Int'l Conference on Computer Communications and 40 "SEAM: Scalable and Efficient ATM Multipoint-to- 

Networks, (San Francisco), September 1994]. However, it Multipoint Multicasting", In Preparation. 

should be also be noted that most networks exhibit a certain (1) Cut-Through Switching 

degree of hierarchy. Even in a local area network, where the As described in the Overview section, a defining property 

network may be physically connected in an arbitrary mesh, of the SEAM methodology is the use of a shared tree 

the routing layer typically organizes the network in a hier- 45 between all senders and receivers. In the context of an ATM 

archical fashion. Given this hierarchy, it can be expected that network, this translates further into a commonly designated 

sender-based trees will not offer significantly different VC serving all senders and all receivers in a group (as well 

delays than shared trees, because the hierarchical structure as a single VC per link). In order for this shared tree 

reduces the number of alternative paths from a sender to a multicasting methodology to work, it is necessary to be able 

receiver. For example, a campus network is usually con- 50 to map multiple incoming VCs into one or several outgoing 

nected to the Internet over a single leased line. This may be VCs at switches. While such mapping is straightforward at 

the most likely bottleneck in a wide-area multicast session. the packet level, a sub-packet network such as ATM intro- 

Both shared trees and sender-based trees would have to duces a substantial complication to such a mapping process, 

choose this link to reach all members on the campus. In a preferred embodiment of the invention, it is assumed 

The multicast methodology of the invention manages 55 that the ATM cells are constructed in accordance with the 

group members who are only senders, only receivers, or AAL5 adaptation layer protocol, which is commonly 

both, in the same way. All of these three types of members applied for data transfer applications using ATM. With that 

share one tree, rooted at the core. The tree's links are AAL5 protocol, a packet is broken up into a number of ATM 

bi-directional channels. The core may be an ATM switch cells, where those cells are sequentially ordered and related 

which provides the added role of being an anchor for 60 to the underlying packet by the VC identifier and an "end of 

signalling messages to be sent toward it, when senders/ packet" marker. And, as explained above, the shared tree 

receivers are added. Segmentation-reassembly is not concept of the invention translates into a commonly desig- 

required at the core and only occurs in the end-systems that nated VC serving all senders and all receivers in a group, 

are senders and receivers. This of course means that multiple links will carry this 

This approach achieves the desired symmetry between 65 commonly designated VC, and at least in some instances 

senders and receivers — i.e., a large sender population is no two or more such links will be connected to input ports of 

more of a scalability concern than a large receiver popula- a single switch. Now, since a particular packet is identified 
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by its VC, the occurrence of a common VC at multiple input signaling messages from, or in behalf of, each of the senders 

ports of a switch would result in chaos if the switch mapped and/or receivers in the multicast group.] Packets X and Y are 

from input to output ports in the straightforward manner. distinguished because of the fact that they arrive on different 

That is, if such mapping is done simply on a cell-by-cell input ports of the switch, even though they arrive on the 

basis (by VC identifier and in the order received), then cells 5 same logical VC. 

belonging to different packets (and contemporaneously Now, as previously noted, because the cell is the unit of 

arriving at different input ports, but identified by the com- transmission, rather than a packet, if the cells from packets 

mon VC) will interfere with each other — more particularly, X and Y, arriving at input ports 1 and 2, were forwarded 

such cells will be interleaved, resulting in corruption of the without regard to packet association for the cells, it is likely 

underlying packets. 10 that such forwarded cells will be interleaved. Thus it can be 

As noted in the Background section, this problem has seen that forwarding cells in the order received, independent 

been addressed in the prior art by reassembling the packets, of which port at which they have arrived, on the same 

performing packet-level scheduling, and re-segmentation of outbound VC is undesirable. To overcome this problem, the 

one packet after the other into the out-bound point-to- invention operates to effectively replicate the behavior of 

multipoint VC (or mesh of point-to-point VCs). A multicast 15 packet networks. That is, the cells comprising an entire 

server is typically used to do this function of reassembly and packet, as received at an input port, are forwarded before any 

forwarding. This approach makes for an obvious perfor- cells received on another input port may be forwarded. In 

mance bottleneck and means that switches have to process this manner, the receivers do not have to distinguish cells of 

packets. With the methodology of the invention, as dis- different packets arriving on the same VC (which would, in 

cussed below, it is possible to achieve the same result 20 any event, be an impossible task). 

without reassembly and segmentation. This cut-through process of the invention is carried out by 

With the AAL5 protocol, the constraint imposed by ATM having the following actions carried out at the switch: the 

is that the data on a particular VC is ordered. Given that first cell of a packet arriving from any input port on VC H 

ordering, and the fact that the ATM cell header contains an determines that this packet arriving on that input port gets 

end-of-packet (EOP) designator, the cells comprising a 25 unconditional priority to be forwarded on the outgoing VC 

packet may be determined from the VC identifier. When a H. Let this packet be Y from source B. Then, all of the cells 

cell containing the EOP flag is received, all the previous of packet Y are forwarded first Any other packet arriving on 

cells received on that VC are understood to belong to that any other input port is queued at the switch for forwarding 

packet. subsequent to the transmission of packet Y. For example, 

With multiple senders transmitting to the same multicast 30 since, under the illustrative hypothesis, the first (and hence 

group, however, these communications arrive on the same all) of the cells of packet X are received after the first cell 

commonly-designated VC. Thus, it will be readily appreci- of packet Y is sent, these are queued. When the last cell of 

ated that when multiple senders send packets on the same packet Y (signified by the EOP cell, and designated 5Y in the 

VC, these packets need to be unambiguously ordered and figure) is transmitted, then the cells queued for packet X are 

forwarded so that there is no corruption of the data trans- 35 transmitted from the switch on the spanning tree. From that 

missions. As explained above, such unambiguous ordering point onwards, packet X gets priority for being transmitted 

and forwarding cannot be accomplished with a straightfor- on VC H until it has been completely forwarded by the 

ward mapping of input VCs to output VCs. However, with switch. Although the cut-through function described herein 

the SEAM methodology such unambiguous ordering and has been illustrated in the context of a single switch, it 

forwarding is accomplished by having the switches perform 40 should be understood that this function would be imple- 

a function designated as cut-through. Switches performing mented for each switch in the shared tree, 

this cut-through function forward complete packets at a Thus, it will be seen that the requirement on a switch in 

time, while buffering incoming packets from other input the shared tree performing "cut-through" is to identify the 

ports until the complete packet has been forwarded, as first cell of an incoming packet on a given multicast VC H, 

indicated by the forwarding of an EOP cell for the currendy 45 and to transmit cells received on that input port only, until 

"being forwarded" packet. the last cell of that packet has been transmitted. The cells 

To illustrate the operation of this cut-through function, from other input ports that arrive in the meanwhile on VC H 

consider the case where two senders, A and B are transmit- are queued for forwarding subsequent to sending the last cell 

ting data packets X and Y to a set of receivers, as depicted of the currently being forwarded packet, 

in FIG. 2. These data arrive at input ports 1 and 2, 50 In a further manifestation of the cut-through 

respectively, for the indicated switch, which is illustrative of methodology, the switch may be arranged to consider the 

one of the switches in the shared tree. If the networks were network transmission speed for packets being received at an 

packet-based, rather than ATM, where packets were not input port. For example, it may be known that the transmis- 

being segmented into cells, the action of cut-through for- sion speed for packets received at a particular input port will 

warding is simple: packet X would be transmitted and 55 below — possibly because the port itself is slow, or possibly 

subsequently packet Y would be transmitted, both being because the VC on that port has low bandwidth. In that case, 

identified by the handle H, which is the group handle. forwarding priority may not be granted on the basis of the 

Whichever packet arrived first gets transmitted first. first input port to receive cells of a new packet. Rather, 

With ATM networks, however, packets are segmented where such an input port (or the VC on that port) is 

into cells and senders A and B transmit packets X and Y, with 60 characterized by a slow transmission speed, cells coming 

the same VC, which illustratively is designated as VC H. into that port may be buffered and the cells arriving at a 

[Note that, while it is convenient for illustrative purposes to higher-speed port forwarded (even though not first in time of 

assume that all VCs are commonly designated by the group arrival at the switch) while the full packet is received for the 

handle, "H", in practice each switch port is likely to have a slower input port. This provides the obvious advantage of 

different designation for the group VC, with the association 65 avoiding a delay in forwarding packets from higher speed 

of such different VC designations to the group handle being ports due to the switch being tied up waiting for a low speed 

maintained in routing tables in the switches, based on packet to be completely processed through the switch. 



12/17/2003, EAST Version: 1.4.1 



US 6,3; 

11 

As a still further manifestation of the cut-through 
methodology, a time-out mechanism can be implemented for 
the case of the EOP cell of a packet being lost. As will be 
apparent, with the SEAM methodology, the loss of the EOP 
marker affects the forwarding of packets on other input 
ports. To overcome this problem, a time-out may be pro- 
vided in the cut-through process, in respect to the waiting 
time for an additional cell on a VC at an input port. Upon 
timeout, the switch may regenerate a "dummy" EOP cell for 
the given VC, so that such dummy EOP cell can be 
forwarded, complete the packet, and thus allow other pack- 
ets to now be forwarded from other input ports. As will be 
understood, such a time-out procedure is only needed when 
a packet is currently being cut through and the EOP cell has 
not yet been received at the input port. 

(2) Creation of Multicast Group 

When senders or receivers want to join a multicast group, 
a join message (i.e., a signalling message using the group 
handle) needs to be sent towards the core. To that end, the 
choice of a core needs to be made prior to setting up any part 
of the multicast tree. A question thus arises as to what entity 
has responsibility for setting up the core? 

In one embodiment of the invention, an "initiator", who 
may or may not be a future member of the group, will be 
responsible for defining the core and disseminating the 
existence of the core to the potential members. This can 
happen, for example, through a name service, as proposed in 
Ballardie, et al., id., or through directly contacting the 
members, depending on the semantics of the group. 

In an alternative embodiment, it does not need to be the 
initiator's responsibility to choose what switch in the net- 
work is elected as core. Such a selection can be made by the 
network itself, typically in the form of a core selection 
service. The initiator could provide information about 
expected group membership (e.g., geographical 
information) in order for the network to optimize the choice 
of a core. The network answers a core selection request with 
a handle that the initiator may use to advertise the group. 

(3) Signalling for Member and Core Initiated Joins 

It will be apparent that member-initiated joins are highly 
desirable for a scalable multicast service. The advantages of 
a member initiated join approach over a root initiated 
approach are twofold. First, the root (or core) of a multicast 
tree does not need to know about or keep track of the 
membership of the group. This results in a saving of 
processing resources and state space. Second, a join to a 
group that already has a tree set up can be terminated at the 
point where a new branch will be added to the existing tree. 
This translates into a saving of bandwidth (due to signalling 
messages travelling smaller distances, or hops), processing 
resources in the switches and reduced latency. 

New members who wish to join the multicast group either 
as senders or receivers issue a join request. This join request 
travels towards the core on the shortest path, until it hits a 
switch that is already on the requested group's tree. A new 
branch is then created from that switch to the joining 
member. Essentially, the procedure is comparable to that of 
receivers joining a point-to-multipoint VC in the ATM 
User-Network Interface Signalling Specification, Version 
4.0 [P. Samudra, "UNI Signalling 4.0 (draft)", ATM Forum/ 
95-1434R9, December 1995, but is generalized to both 
sending and receiving members. Options similar to those 
proposed in the December 1995 UNI 4.0 draft (i.e., without 
sender participation, with sender notification, with sender 
permission) can be used. 

While member initiated joins are clearly necessary, it 
should be apparent that core initiated joins should be avail- 
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able as well. For example, if the initiator knows who the 
group members are going to be (e.g., because the application 
requires a well-defined set of members), then it would be 
much easier and more efficient for the initiator to be able to 

5 tell the core, upon setup, what hosts to connect to the group, 
instead of setting up the core, and then contacting each 
member individually and invite the member to join. 
(3a) Use of a Receivers Downstream (RD) Bit 
The use of a single shared tree among all receivers and 

10 senders requires the introduction of a small amount of 
per-link state to avoid wasting resources, such as transmit- 
ting to sender-only end-systems. In order to avoid forward- 
ing packets to members who are only senders, a flag may be 
associated with the group at each "on-tree" switch. The flag, 

15 designated as the "Receivers Downstream" bit, indicates if 
there are any receivers downstream from this port. Consider 
the network configuration depicted in FIG. 3(a). The des- 
ignation RD«0 at switch SI means that this port only has 
senders downstream, and therefore no packets need to be 

20 forwarded on this port. 

If a new receiver connects to the existing tree at a port that 
has the RD bit cleared, as indicated by the dashed connec- 
tion at switch S2 in FIG. 3(fc), then the forwarding tables in 
some upstream switches have to be updated, such that 

25 packets will be forwarded down to the new receiver. The join 
request therefore has to travel towards the core on the tree 
and update the forwarding table in each switch. The join 
request stops when it hits a switch with the RD bit set on at 
least one other port, which means that packets sent to the 

30 group already reach this switch. At each switch traversed on 
the tree, forwarding tables have to be updated such that 
packets will be forwarded towards the new receiver. 
(4) Short Cutting 

In a further embodiment of the invention, an additional 

35 improvement in the efficiency of the SEAM multicasting 
methodology is realized by implementation of a process 
designated as short cutting. With the short cutting process, it 
is possible in many cases to avoid having the transmissions 
go to the core before being forwarded to the receivers. The 

40 operation of short cutting is illustrated in FIG. 4, which also 
provides a useful depiction of the way in which incoming 
VCs are mapped to outgoing VCs in accordance with routing 
table entries (which routing table entries have themselves 
been established on the basis of the handle for a given 

45 multicast group). 

Consider switch S a in the figure, which is exemplary of 
the short cutting process, and particularly a message being 
sent from sender SI to members of its multicast group. As 
can be seen, that message from sender SI will arrive at port 

50 1 of switch S x on VC1. In the exemplary routing table for 
switch S 1? which shows only entries corresponding to the 
multicast group of interest, input ports, and corresponding 
VCs for the multicast group are represented as rows of the 
table, with output ports being represented as columns. 

55 Entries in the table correspond to output ports and associated 
VCs to which messages arriving from a designated input 
port/VC should be forwarded. From the configuration in the 
figure, it can be seen that, in the absence of short cutting, the 
message from sender SI would only be forwarded toward 

60 the core via output port 3 and VC5, corresponding to the 
table entry for input port 1/VC1, and thus, for that message 
to reach receiver R2, it would need to travel to the core via 
switch Sj, and then back to receiver R2 via switches S 2 and 
S r 

65 With short cutting, however, an entry is placed in the 
routing table (for input port 1/VC1 and output port 2) 
showing that a receiver member of the multicast group (Rl) 
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is joined to the group at that switch. Thus the message from 
sender SI is caused to be forwarded directly to receiver Rl 
via output port 2/VC2, rather than having to be sent all the 
way to the core and back. Short cutting is also illustrated at 
switch S 2 with respect to a message from sender SI for 
receiver/senders RS3 and RS4. 

For the more general case of short cutting, anytime a cell 
is received at a switch S on a VC H, where context for VC 
H has been established at the switch (i.e., the switch knows 
it is in the spanning tree for conversation H), then the switch 
forwards the arriving cell on all the links of the spanning tree 
other than the one it was received on — subject to the 
constraint that, where the "Receivers Downstream" (RD) bit 
is used, forwarding will only occur on the links where the 
RD bit is set 

The switch also forwards the packet up to the core for 
forwarding to receivers on the "other side" of the core. The 
same principles will be applied as if the core is another 
receiver (i.e., the packet is not forwarded to the core on a 
link if it arrived from an input link that is on the shortest path 
to the core, following RPF rules). 

With the short-cut process implemented, the core also has 
less work to do: it needs only to forward cells on the other 
spanning tree's links, not the link on which the cell was 
received. If, for example, there were only one outgoing link 
from the core for the spanning tree, and this was the link on 
which the cell was received, the core has no forwarding task 
to perform. 

The core generally acts as any other SEAM switch. The 
one exception is that all data gets forwarded to the core, even 
if it does not have receivers on its other ports. In this case, 
the RD bit is not helpful since receiver joins only go as far 
as the core. There is no clean way to have the signalling 
progress beyond the core to the set of switches 
downstream — i.e., to the point where switches are reached 
that all have their RD bit set. Therefore, by requiring the data 
to be forwarded to the core, irrespective of the RD bit, 
switches in the tree are led to believe that there are always 
receivers downstream of the core. 

Another gain for short-cutting is reduced latency, because 40 
packets between nearby sender-receiver pairs do not have to 
go through the core first. Finally, it should be understood that 
short-cutting is enabled by modifications in the signalling 
path of the switch implementation, and does not require any 
changes in the data path. 

(5) Migration Methodology 

It is believed that the cut-through capability contemplated 
by the SEAM methodology will be readily implemented in 
current and future generation ATM switches. However, 
many ATM networks will also include older generation 
switches which may not have the capability to implement 
that cut-through procedure. Accordingly, as a still further 
embodiment of the invention, a methodology is described 
herein for implementation of the SEAM methodology in a 
hybrid ATM network comprised of some ATM switches 
capable of effecting cut-through and some which lack that 
capability. In other words, an interoperability architecture is 
provided between non-SEAMable islands, (i.e., one or sev- 
eral switches not having the cut-through capability) and 
SEAM environments. 

Consider the network configuration shown in FIG. 5. 
There, an island of two non-SEAMable switches, S2 and S3, 
is shown interconnected into a network with 3 SEAM 
switches, SI, S4 & S5. The interoperability issues which 
must be addressed are: (a) How may the SEAMable 
switches having a SEAM multipoint-to-multipoint VC 
belonging to the same group be connected to the island of 
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non-SEAMable switches? (b) How may senders and receiv- 
ers inside the non-SEAMable island be connected to the 
SEAM group? An assumption is made that the switches in 
the non-SEAMable island have the capability of setting up 
point-to-multipoint VCs, at least as specified in UNI 4.0. 

To effect an efficient use of signalling resources, the 
concept of an SD-bit (sender-downstream) is introduced at 
each SEAMable switch. This bit is used to allow a SEAM- 
able switch to set up connectivity to the non-SEAMable 
island for forwarding transmissions of the group from send- 
ers on the SEAM environment. The methodology for 
addressing these issues and for achieving the desired 
interoperability is as follows: 

Each sender (Sndl) in the non-SEAMable island sets up 
a point-to-multipoint VC, rooted at itself, reaching all 
island receivers (Rcvl, Rcv2) as well as all border 
SEAM switches having the RD bit set on at least one 
port, other than the one connected to the island (e.g., at 
switches SI, S4). 
Each border SEAM switch having the SD bit set 
(indicating a downstream sender on at least one other 
port than the one connected to the island), e.g., SI, sets 
up a point-to-multipoint VC to all the non-SEAMable 
island receivers (Rcvl, Rcv2) as well as the other 
bordering SEAM switches having the RD bit set on at 
least one other port than the one connected to the island 
(e.g., S4). The SD (Sender Downstream) bit, analogous 
to the RD bit, determines if there are senders on the 
other ports than the one connected to the island. If the 
SD-bit is not set, then the point-to-multipoint VC into 
the island rooted at that switch is not necessary. This 
avoids the signalling message making progress and a 
VC being set up unnecessarily. Note that it is enough to 
have an SD bit per switch, not per port. 
Border SEAM switches (SI, S4) map all of the incoming 
point-to-multipoint VCs from the island into the SEAM 
multipoint-to-multipoint VC on the other ports. 
Reverse Path Forwarding is done per port (not per 
switch), i.e. an incoming VC from the non-SEAMable 
island is not forwarded into the point-to-multipoint VC 
back to the island. 
Border SEAM switches map the point-to-multipoint VC 
into the island into the SEAM multipoint-to-multipoint 
VC as well. 

This approach has the following properties. First, SEAM 
switches not connected to an island do not need to have any 
knowledge about the island (e.g., S5). Second, border 
SEAM switches (SI, S4) need to know about all of the 
non-SEAMable island senders (e.g., Sndl) (in order to do a 
leaf-initiated join to the point-to-multipoint VC rooted at 
these senders) as well as about other border SEAM switches 
(for the same purpose). The same holds for island receivers 
(Rcvl, Rcv2). Basically, inside the island, the situation is as 
if there were no SEAM multipoint-to-multipoint VCs. Bor- 
der SEAM switches are, in the general case, both senders 
and receivers. Third, as sbort-cutting is "emulated" inside 
the island with multiple point-to-multipoint VCs, the same 
delay is realized as if there were only SEAM switches. 
Fourth, scalability in terms of sender population is obviously 
not achieved inside the island, as the number of point- to- 
multipoint VCs grows with the number of senders and 
bordering SEAM switches. However, the approach is scal- 
able in the number of islands; each island is isolated in the 
sense that it does not need to know about other islands. 
Conclusion 

An efficient methodology for providing multipoint-to- 
multipoint communication in ATM networks has been 
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described herein. The methodology of the invention allows 
for scaling up to a large number of potential senders and 
receivers. There is a single shared spanning tree for all 
senders and receivers. A unique handle is used, which 
enables switches in the spanning tree to translate to a single 
VC on a link, for identification of any packets associated 
with a given multicast group. That handle is a tuple (core 
address, unique-id at core) that is unique across the network. 
Each multicast group has an associated "core", which is used 
as the focal point for routing signalling messages for the 
group. However, at the data forwarding level (as opposed to 
signalling), the core essentially operates as just another 
switch in the spanning tree. Leaf -initiated joins to the single 
core-based tree are allowed by senders and receivers as well 
as core-initiated joins. 

Two unique features are incorporated in the SEAM meth- 
odology: "cut-through" forwarding and "short-cutting" to 
achieve efficient multicasting with low-latencies for com- 
munication between senders and receivers. Cut-through 
forwarding in a switch enables the mapping of several 
incoming VCs into one or more outgoing VCs at a switch. 
A switch capable of cut-through forwards a multicast packet 
from one input port at a time, taking advantage of the an 
end-of-packet marker to identify when to "switch" to for- 
warding a new packet. Incoming packets from other input 
ports are buffered until it is their turn, thus ensuring packets 
are transmitted on an outgoing VC "atomically , ^ "Short- 
cutting" is entirely in the signalling path in switches, and 
allows a packet to follow the shortest path along the shared 
tree spanning all senders and receivers of the group, thus 
avoiding a packet having to go all the way to the core and 
then be forwarded to the receivers. Finally, a means is 
provided for implementation of the methodology of the 
invention in a hybrid ATM network comprised of some ATM 
switches capable of effecting the method of the invention 
and some which lack that capability. 

Although the present embodiment of the invention has 
been described in detail, it should be understood that various 
changes, alterations and substitutions can be made therein 
without departing from the spirit and scope of the invention 
as defined by the appended claims. 

What is claimed is: 

1. A cell transfer network which is made up of a plurality 
of nodes and transmission links interconnecting said nodes, 
including means for establishing at least one logical con- 
nection among a set of said nodes for effecting a transfer of 
a sequence of said cells from at least one sending node to at 
least one receiving node, said network including the 
improvement comprising: 

means for responding to a specification of a multipoint- 
to -multipoint multicast group using said network by 
specifying a single spanning tree for said multicast 
group, said spanning tree comprising switching nodes 
and links in said network connecting sending and 
receiving nodes in said multicast group, at least one of 
said switching nodes in said spanning tree established 
as a core node for said tree; 
means for responding to a request by any one of said 
sending nodes to send at least one sequence of said cells 
to receiving nodes in said multicast group via logical 
connections established in said spanning tree; and 
means for causing another switching node in said span- 
ning tree to operate on a cell sequence from a sending 
node in said multicast group transmitted toward said 
core node so as to cause a copy of said cell sequence to 
be provided directly to a receiving node in a hierarchy 
of said spanning tree at or below a location in said 
hierarchy of said another switching node. 
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2. The improved cell transfer network of claim 1 wherein 
said means for establishing at least one logical connection 
operates to establish at most one logical connection per fink 
of said spanning tree. 
5 3. The improved cell transfer network of claim 1 wherein 
said means for establishing at least one logical connection 
operates to establish a common logical connection for all 
links in said spanning tree. 

4. The improved cell transfer network of claim 1, claim 2 
10 or claim 3, wherein a switching node in said spanning tree 

receives input cell sequences from a multiple of said sending 
nodes in said multicast group, further including means for 
causing said switching node to completely process a cell 
sequence received from a first input path prior to processing 
is any portion of another cell sequence received from another 
of said multiple input paths. 

5. The improved cell transfer network of claim 1, claim 2 
or claim 3, further including means for causing at least one 
of said switching nodes in said spanning tree to maintain a 

20 marker at respective ports of said at least one switching node 
for each of said respective ports serving a receiving node of 
said multicast group downstream in said spanning tree from 
said respective port 

6. A method employed in a cell transfer network having 
25 a plurality of nodes and links to add an additional sending/ 

receiving node to a set of nodes which belong to a 
multipoint-to-multipoint multicast group, 
the method having the steps of: 

sending a message via a spanning tree in said network 
30 associated with said multicast group from said addi- 
tional sending/receiving node toward a core node of 
said multicast group indicating that said additional 
node is to be added to said multicast group; and 
35 adding said additional node and any nodes traversed by 
said message which are not already in said spanning 
tree to said spanning tree. 

7. The cell transfer network method of claim 6 including 
the additional step of causing at least one of said nodes 

^ traversed by said message to maintain a marker at respective 
ports of said at least one node for each of said respective 
ports serving a receiving node of said multicast group 
downstream in said spanning tree from said respective port. 

8. The cell transfer network method of claim 7 including 
45 the further step of causing at least one of said nodes 

traversed by said message to operate on a sequence of said 
cells received at an input port of said at least one node from 
a sending node in said multicast group so as to cause a copy 
of said cell sequence to be transferred to an output port 
50 connected to a receiving node in said multicast group 
located downstream in said spanning tree. 

9. A method for multipoint-to-multipoint routing of com- 
munications traffic among a plurality of information sources 
and information sinks connected to a communications 

ss network, said network being comprised of interconnected 
switching nodes and transmission links defining transmis- 
sion paths in said network, wherein said communications 
network is arranged to transmit information within said 
network in the form of discrete units, said methodology 
6Q comprising the steps of: 

specifying a unique identifier for association with each of 
a set of said information sources and information sinks, 
said set of sources and sinks constituting a multicast 
group; 

65 selecting at least one switching node in said network to act 
as an anchor for signalling messages sent toward said 
anchor from sources/sinks constituting said multicast 
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group, said anchor and a set of paths for said signalling 
messages constituting a spanning tree for said multicast 
group; 

providing communications paths in said spanning tree, for 
transmission of information among members of said 
multicast group; and 

where a switching node in said spanning tree includes 
multiple input paths, from a multiple of said sources in 
said multicast group, causing said switching node to 
completely process an information segment of pre- 
defined size received from a first input path prior to 
processing any portion of another information segment 
received from another of said multiple input paths. 

10. The method for routing multipoint-to -multipoint com- 
munications traffic of claim 9 including an additional step of 
causing a switching node in said spanning tree to operate on 
an information unit from an information source in said 
multicast group transmitted toward said anchor, so as to 
cause a copy of said information unit to be provided directly 
to an information sink in a hierarchy of said spanning tree at 
or below a location in said hierarchy of said switching node. 

11. The method for routing multipoint-to-multipoint com- 
munications traffic of claim 9 wherein said unique identifier 
includes an address for said anchor and at least one other 
identification parameter. 

12. The method for routing multipoint-to-multipoint com- 
munications traffic of claim 9 wherein said communications 
paths in said spanning tree establish a shortest path within 
said network between each of said sources/sinks and said 
anchor. 

13. The method for routing multipoint-to-multipoint com- 
munications traffic of claim 9 wherein said communications 
paths in said spanning tree establish a least-cost routing 
within said spanning tree. 

14. The method for routing multipoint- to-multipoint com- 
munications traffic of claim 9, wherein a last portion of each 
said predefined segment is identified by an end-of-segment 
marker and said switching node operates to recognize said 
end-of-segment marker prior to accepting for processing 
information from said another input path. 

15. The method for routing multipoint-to-multipoint com- 
munications traffic of claim 9 wherein said communications 
paths in said spanning tree are constituted as not more than 
one logical connection per link. 

16. The method for routing multipoint-to -multipoint com- 
munications traffic of claim 9 wherein all of said commu- 
nications paths in said spanning tree are associated with a 
common logical connection. 

17. The method for routing multipoint-to-multipoint com- 
munications traffic of claim 9 wherein said communications 
network operates in accordance with a networking protocol 
known as Asynchronous Transfer Mode ("ATM") and 
wherein said units for transmission of information within 
said network are established as cells, as defined by said ATM 
protocol. 

18. The method for routing multipoint-to-multipoint com- 
munications traffic of claim 17 wherein said predefined 
information segment operated on by said step of causing 
each said switching node in said tree to completely process 
said predefined segment is constituted as a grouping of said 
ATM cells. 

19. The method for routing multipoint-to-multipoint com- 
munications traffic of claim 18, wherein a last cell in each 
said grouping of ATM cells is identified by an end-of- 
segment marker and said switching node operates to recog- 
nize said end-of-segment marker prior to accepting for 
processing information from said another input path. 
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20. The method for routing multipoint-to-multipoint com- 
munications traffic of claim 19 wherein said grouping of 
ATM cells is constructed in accordance with an adaptation 
layer protocol designated as AAL5, and further wherein said 
end-of-segment marker is as defined by said AAL5 protocol. 

21. The method for routing multipoint-to-multipoint com- 
munications traffic of claim 9 wherein membership of said 
information sources and said information sinks in said 
multicast group may be dynamically adjusted. 

22. The method for routing multipoint-to-multipoint com- 
munications traffic of claim 21, wherein said dynamic mem- 
bership changes occur in response to a request from a 
source/sink for a join to or leave from said membership. 

23. The method for routing multipoint-to-multipoint com- 
munications traffic of claim 22 wherein said membership 
changes occur without notification of said change to said 
anchor. 

24. The method for routing multipoint-to-multipoint com- 
munications traffic of claim 21, wherein said dynamic mem- 
bership changes occur in response to a direction from said 
anchor. 

25. The method for routing multipoint-to-multipoint com- 
munications traffic of claim 21, wherein said dynamic mem- 
bership changes occur in response to a request from a third 
party. 

26. The method for routing multipoint-to-multipoint com- 
munications traffic of claim 9 including the further step of 
causing at least one of said switching nodes in said spanning 
tree to maintain a marker at respective ports of said node for 
each of said respective ports serving an information sink of 
said multicast group downstream from said respective port. 

27. The method for routing multipoint-to-multipoint com- 
munications traffic of claim 26 wherein said switching nodes 
operate to avoid transmitting information units to portions of 
said tree connected to ports not having said marker. 

28. The method for routing multipoint-to-multipoint com- 
munications traffic of claim 9 wherein the step of causing 
each said switching node to completely process an informa- 
tion segment includes the substep of: 

recognizing a port serving one of said multiple input paths 

having low transmission throughput; 
causing information segments arriving at said low trans- 
mission throughput port to be buffered until a complete 
one of said information segments has been received at 
said port, regardless of when a first portion of said 
segment is received at said port relative to an arrival 
time for a segment portion at a port serving another of 
said multiple input paths. 

29. The method for routing multipoint-to-multipoint com- 
munications traffic of claim 9 wherein the step of causing 
each said switching node to completely process an informa- 
tion segment includes the substep of: 

establishing a waiting time threshold in respect to a time 
interval between receipt at an input port of a portion of 
an information segment and a next portion of said 
segment, said next portion being inclusive of said final 
portion having said end-of-segment marker; and 
where said time interval exceeds said threshold, causing 
said switching node to inject a "dummy" end-of- 
segment portion at said input port, thereby causing 
processing of said information segment to be com- 
pleted by said switching node and processing of a new 
information segment to begin. 

30. In a communications network comprised of intercon- 
65 nected switching nodes and transmission links defining 

transmission paths therein, wherein said communications 
network is arranged to transmit information within said 
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network in the form of discrete units, an improvement in 
said network for enabling multipoint- to -multipoint multicast 
routing of communications traffic among a plurality of 
information sources and information sinks connected to said 
network, said improvement comprising: 5 
means for causing a unique identifier to be associatiated 
with a set of information sources and information sinks 
comprising a multicast group; 
means for selecting at least one switching node in said 
network to act as an anchor for signalling messages 10 
sent toward said anchor from said set of sources/sinks 
in said multicast group, said anchor and a set of paths 
for said signalling messages constituting a spanning 
tree for said multicast group; 
means for providing communications paths in said span- 15 
ning tree, for transmission of information among mem- 
bers of said multicast group; and 
where a switching node in said spanning tree includes 
multiple input paths, from a multiple of said sources in 
said multicast group, means for causing said switching 
node to completely process an information segment of 20 
predefined size received from a first input path prior to 
processing any portion of another information segment 
received from another of said multiple input paths. 

31. The improved network for routing of multipoint- to- 
multipoint communications traffic of claim 30 further 25 
including means for causing a switching node in said 
spanning tree to operate on an information unit from an 
information source in said multicast group transmitted 
toward said anchor, so as to cause a copy of said information 
unit to be provided directly to an information sink in a 30 
hierarchy of said spanning tree at or below a location in said 
hierarchy of said switching node. 

32. The improved network for routing of multipoint- to- 
multipoint communications traffic of claim 30 wherein said 
unique identifier includes an address for said anchor and at 35 
least one other identification parameter. 

33. The improved network for routing of multipoint- to- 
multipoint communications traffic of claim 30, further 
including means for recognizing an end-of-segment marker 
included in a last portion of each said predefined segment, 40 
prior to accepting for processing information from said 
another input path. 

34. The improved network for routing of multipoint-to- 
multipoint communications traffic of claim 30 wherein said 
communications network operates in accordance with a 45 
networking protocol known as Asynchronous Transfer 
Mode ("ATM") and wherein said units for transmission of 
information within said network are established as cells, as 
defined by said ATM protocol. 

35. The improved network for routing of multipoint-to- 50 
multipoint communications traffic of claim 30 further 
including means for causing at least one of said switching 
nodes in said spanning tree to maintain a marker at respec- 
tive ports of said node for each of said respective ports 
serving an information sink of said multicast group down- 55 
stream from said respective port. 

36. The improved network for routing of multipoint- to- 
multipoint communications traffic of claim 35 where said 
switching nodes operate to avoid transmitting information 
units to portions of said tree connected to ports not having 60 
said marker. 

37. The improved network for routing of multipoint-to- 
multipoint communications traffic of claim 30 wherein said 
means for causing each said switching node to completely 
process an information segment further includes: 65 

means for recognizing a port serving one of said multiple 
input paths having low transmission throughput; and 



means for causing information segments arriving at said 
low transmission throughput port to be buffered until a 
complete one of said information segments has been 
received at said port, regardless of when a first portion 
of said segment is received at said port relative to an 
arrival time for a segment portion at a port serving 
another of said multiple input paths. 

38. The improved network for routing of multipoint- to- 
multipoint communications traffic of claim 33 wherein said 
means for causing each said switching node to completely 
process an information segment further includes: 

a waiting time threshold in respect to a time interval 
between receipt at an input port of a portion of an 
information segment and a next portion of said 
segment, said next portion being inclusive of said final 
portion having said end-of-segment marker; and 

where said time interval exceeds said threshold, means for 
causing said switching node to inject a "dummy** 
end-of-segment portion at said input port, thereby 
causing processing of said information segment to be 
completed by said switching node and processing of a 
new information segment to begin. 

39. In a communications system for carrying out the 
multipoint-to-multipoint routing methodology of claim 9 
(hereafter, the "SEAM" methodology) among a defined 
multicast group of senders and receivers, wherein said 
communications system is operated across a communica- 
tions network comprised of a plurality of switching nodes 
and interconnecting transmission links, and further wherein 
said plurality of switching nodes includes a first portion 
characterized as being operable to fully implement said 
SEAM methodology (hereafter, "SEAMable nodes") and a 
remaining portion being incapable of fully implementing 
said SEAM methodology (hereafter, "nonSEAMable 
nodes"), a method for effecting interoperability between said 
SEAMable nodes and said nonSEAMable nodes in carrying 
out said SEAM methodology across said network, said 
method comprising the steps of: 

identifying nonSEAMable nodes_ in said network and 
designating each contiguous grouping of one or more 
of said nonSEAMable nodes as a nonSEAMable 
island; 

identifying SEAMable nodes that directly interface nodes 
included in each said nonSEAMable island (hereafter 
designated as "border SEAMable nodes"); 

establishing, for each of said senders served by a non- 
SEAMable island node, a point-to-multipoint virtual 
connection reaching all of said receivers served by 
nodes in said nonSEAMable island and all border 
SEAMable nodes interfacing said nonSEAMable 
island; 

establishing, for each of said border SEAMable nodes 
interfacing said nonSEAMable island, a point-to- 
multipoint virtual connection to all of said receivers 
served by nodes in said nonSEAMable island and all 
remaining of said border SEAMable nodes interfacing 
said nonSEAMable island; 

causing each of said border SEAMable nodes to map all 
incoming point to multipoint virtual connections from 
said nonSEAMable island into a SEAM multipoint-to- 
multipoint virtual connection established for said mul- 
ticast group on other ports of each said border SEAM- 
able nodes; and 

causing each of said border SEAMable nodes to map all 
outgoing point to multipoint virtual connections to said 
nonSEAMable island into said SEAM multipoint-to- 
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multipoint virtual connection established for said mul- 
ticast group on other ports of each said border SEAM- 
able nodes. 

40. The method for effecting interoperability between 
SEAMable nodes and nonSEAMable nodes of claim 39 5 
including the further steps of: 

causing a first marker to be maintained at said border 
SEAMable nodes when at least one sender of said 
multicast group is served by a port of said border 
SEAMable node other than a port serving said non- 10 
SEAMable island; 

causing a second marker to be maintained at respective 
ports of said border SEAMable nodes serving said 
multicast group for each of said respective ports having 
at least one receiver of said multicast group down- 15 
stream from said respective port; 

for said point-to-multipoint virtual connections estab- 
lished for said senders served by said nonSEAMable 
island nodes, eliminating any of said border SEAMable 2Q 
nodes interfacing said nonSEAMable island as desti- 
nations for said point-to-multipoint virtual connections 
where at least one port of said border SEAMable node 
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other than a port interfacing said nonSEAMable island 
does not exhibit said second marker; and 

for said point-to-multipoint virtual connections estab- 
lished from said border SEAMable nodes to said non- 
SEAMable island, eliminating any of said border 
SEAMable nodes not exhibiting said first marker as 
roots for said point-to-multipoint connection. 

41. The method for effecting interoperability between 
SEAMable nodes and nonSEAMable nodes of claim 40 
including the further step of: 

for respective ones of said border SEAMable nodes 
interfacing said nonSEAMable island serving as roots 
for said point-to-multipoint virtual connections, elimi- 
nating any of said remaining border SEAMable nodes 
as destinations for said point-to-multipoint virtual con- 
nections where at least one port fbr respective ones of 
said remaining border SEAMable nodes, other than a 
port interfacing said nonSEAMable island, does not 
exhibit said second marker. 
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